Day 2. Objectives โครงการส งเสร มให ผ ประกอบการได ร บมาตรฐาน โครงการสงเสรมใหผ ประกอบการไดรบมาตรฐาน ISO/IEC ป งบประมาณ 2561

Transcription

1 ISO/IEC Day 2 โครงการส งเสร มให ผ ประกอบการได ร บมาตรฐาน โครงการสงเสรมใหผ ประกอบการไดรบมาตรฐาน ISO/IEC ป งบประมาณ 2561 depa Digital Transformation Funding ISO/IEC by FTI (IT club) 1 Objectives This training is to aim at the introduction of the concepts for software engineering standardized for VSEs. This course also understands how to use the ISO/IEC to build and assess the quality of the software development processes and product. Attendees will gain all of the following: To provide an understanding of Principle of Continuous Process Improvement To define common approach on software process improvement To provide an understanding of Lifecycle Profile for Very Small Entities (VSEs) To practice interpreting the ISO29110 Standard for examining the software development processes 2

2 Agenda 9:00 12:00 Process Improvement and Standard Concept Process Improvement Process Model Overview ISO/IEC Basic Profiles (PM) Project Management (PM) Workshop 13:00 16:00 ISO/IEC Basic Profiles (SI) Workshop Wrap up 3 PROCESS IMPROVEMENT AND STANDARD CONCEPT 4

3 Principle of Continuous Improvement Total Quality Management (TQM) as a Strategy for Continuous Improvement Business is an evolutionary process Spirit of improvement Culture of continuous improvement There is always an opportunity for improvement 5 Principle of Continuous Improvement (Cont.) Plan/Do/Check/Act (PDCA) Strategy Plan: Choose a problem. Analyze it to find a probable cause. Do: Run an experiment to investigate the probable cause. Check: Analyze the data from the experiment to validate the cause. Act: Refine andstandardize based ontheresults. 6

4 Process Improvement Whether intentional ti or not, you already have processes in place. Are they the RIGHT processes? Something S is wrong if no one uses the processes if everyone has their own interpretation of the process if you find you are always tailoring your processes 7 Critical Success Factors for Process Improvement Commitment C tto improve must start tat the top. First understand the current process. Structured change must become a way of life. Improvement requires investment. When failure occurs, focus on the process, not the people. Institutionalizing improvements requires vigilance and periodic reinforcement. 8

5 Process Improvement Adoption Change Adoption Model: Transition Mechanisms Source: 9 PROCESS OVERVIEW 10

6 Organizations Are Complex Systems Organizational System Inputs Human, Financial, Technological, Material, Resources Strategict Technological l Managerial Outputs Products, Services Human/ Cultural Structural Input-output flow of materials, energy, information Adapted from Kast and Rosenzweig, Symptoms of Project Failure Improper estimation Loose requirements management Weak project management Improper p risk management Poorly engineered solutions Etc. 12

7 Symptoms of Project Failure (Cont.) Quality Problems Too much rework No product documentation Functions that don t work correctly Customer complaints after delivery Delivery of embarrassing products Wide variation in how people p perform identical tasks Work with wrong versions of work products No View to the Future No concern for process improvement No feedback on process effectiveness Program cancellation 13 How Do You Want to Work? Random motion lots of energy, not much progress No teamwork individual effort Frequent conflict You never know where you ll end up Directed motion every step brings you closer to the goal Coordinated efforts Cooperation Predictable results Processes can make the difference! 14

8 What Is a Process? A process is a set of interrelated activities, which transform inputs into outputs, to achieve a given purpose. Result Process Improvement flows from and extends the general management theories developed over the past ~30 years (Juran, Deming, Crosby, etc.) 15 Software Development Lifecycle Overview Requirement Design Implementation ti Testing Release Project Management and Risk Management Configuration Management (Change Management) Verification and Validation (V&V) Process and Product Quality Assurance (PPQA) 16

9 How Can Process Help? Process supports the goals of the company, enabling Repeatability Insight and oversight Control and tracking Measurement Improvement Training Inte erchan geable e part ts Transformation (via consistency, integration, coordination) 17 Quality Leverage Points While process is often described as a leg of the processpeople technology triad, it may also be considered the glue that unifies the other aspects. PROCESS PEOPLE TECHNOLOGY Everyone realizes the importance of having a motivated, quality work force but even our finest people can t perform at their best when the process is not understood or operating at its best. Major determinants e of product cost, schedule, and quality 18

10 Quality Leverage Points (Cont.) Process provides a constructive, ti high leverage h focus... as opposed to a focus on people Your work force, on the average, is as good as it is trained to be. Working harder is not the answer. Working smarter, through process, is the answer. as opposed to a focus on technology Technology applied without a suitable roadmap will not result in significant payoff. Technology provides the most benefit fitin the context tof an appropriate process roadmap. 19 Processes Influence Projects Notone one single project process can solve every projectacross all industries. Many project processes come close to preventing problems, and many are tailored to specific uses, but it finally boils down to applying solid project management principles. p Processes affect project management; they affect any project universally in the sense that each methodology: Contains project phases. Measures progress. Tk Takes corrective actions based on df defects tfound. Assigns resources to various phases. 20

11 Shortcomings of Project Processes Are abstract and high level. Contain insufficient narratives to support these methodologies. Are not functional or do not address crucial areas (i.e., QA, CM, testing). Ignore the industry standards and best practices. Look impressive but lack real integration into the business. Use nonstandard project conventions and terminology. Compete for similar resources without addressing this problem. Don't have any performance metrics. Take too long to complete because of bureaucracy and administration. 21 Characteristics of Effective Processes simple trackable enforced trained Well-defined gates practiced 22

12 Process Centric Approach Simply documenting each and every process and Simply pycommunication strategies can best enable people to seize fleeting opportunities in rapidly changing requirements. Determine your organization s business goals and problem areas first. 23 Key Factors for Defining Processes Provides guidelines for efficient i development of quality systems and solutions. Reduces risk and increases predictability. Captures and presents best practices. Promotes a common vision and culture for the organization. Provides a roadmap for applying li tools and techniques. Easy to understand and simple to use. 24

13 PROCESS MODEL OVERVIEW 25 What Is a Process Model? A model dlis a structured collection of elements that describes characteristics of effective processes. Processes included are those proven by experience to be effective. 26

14 Multiple Process Models 27 Quality Standard Repository ของ ISO ด าน Software 28

15 ISO/IEC : Life Cycle Process Group 29 Multiple Process Models Challenge Have different structures, formats, terms, ways of measuring maturity Cause confusion, especially when more than one are used Are difficult to integrate into a combined improvement program Are dff difficult to use in supplier selection 30

16 Why Is a Model Important? A model provides a place to start the benefit of a community s prior experiences a common language and a shared vision a framework for prioritizing actions a way to define what improvement means for your organization All models are wrong; some are useful. George Box 31 How Is a Process Model Used? A process model dlis used to help set process improvement objectives and priorities to hl help ensure stable, capable, and mature processes as a guide for improvement of project and organizational processes with an appraisal methodology to diagnose the state of improvement efforts 32

17 ISO OVERVIEW 33 What is ISO/IEC 29110? Software Engineering Lifecycle Profiles for Very Small Entities (VSEs) 34

18 What is ISO/IEC 29110? (Cont.) ISO/IEC Title Target Audience Part 1 Overview VSEs Part 2 Framework and Standards producers, tool vendors Taxonomy and methodology vendors. Not intended for VSEs. Part 3 Assessment Guide Assessors and VSEs Part 4 Profile Specifications Standards producers, tool vendors and methodology vendors. Not intended for VSEs. Part 5 Management and Engineering Guides VSEs 35 Basic VSE Profile Preparation 36

19 Basic VSE Profile Preparation (Cont.) a) The recognition of VSE characteristics related to: finance, resources, customer interface, internal business processes, learning and growth. b) The identification of VSE needs and suggested Competencies that derives from those characteristics c) The specification of the Basic VSE Profile elements proper to respond to the VSE needs and suggested Competencies according to ISO/IEC d) The selection and link of the subset of the Basic VSE Profile elements that map to the ISO/IEC processes and outcomes elements and ISO/IEC 15289:2006 product elements related to the Basic VSE Profile elements. e) The definition of the Basic VSE Profile Guides: ISO/IEC TR , Management and Engineering gguide for the implementation of Basic VSE Profile. 37 Implementation of the basic VSE Profile 38

20 ISO/IEC BASIC PROFILE PROJECT MANAGEMENT (PM) SOFTWARE IMPLEMENTATION (SI) 39 Project Management (PM) Profile PM Purpose The purpose of project managementprocess is to establish and carry out in a systematic way the tasks of the software implementation project, which allows complying with the project s objectives in the expected tdquality, time and costs. 40

21 Project Management requirements As a result of successfulimplementation of theproject Managementprocess: a) The scope of the work for the project, including deliverables, shall be defined. b) Tasks and resources associated with scope of the work shall be defined. c) Thecost cost, technical andschedule feasibilityshallshall beperformed. d) Schedule, effort, cost and duration of work shall be estimated. Other metrics should be estimated, if needed. e) Allocation of human resources shall be planned. f) Execution plan of the project shall be developed according to the scope of work, planned dhuman resources and tasks dfi defined. d g) The execution plan shall be agreed by the Customer. h) Risksshallbeidentified shall identified andmonitoredduringtheexecution during the execution ofthe project. 41 Project Management requirements (Cont.) i) A software version control strategy shall be developed and implemented, including back up and restoring definition. j) Relevant items of software configuration shall be identified and controlled, including their storage, baseline, handling, and modifications. k) Progress of the project against the planning shall be monitored and reported. l) Actions to adjust and correct execution plan deviations shall be taken. m) Work team and customer review activities shall be held to assure that the work has been done complies with the software requirements andexecution plan. n) Agreements resulting from revision activities shall be registered and tracked. o) Project closure shall be performed after Customer acceptance. 42

22 PM Activities Input Process Output Related Role(s) Statement S of Work Project P j Plan (SOW) (accepted) PM.1 Project Project Repository Planning PM TL CUS Project Plan Project Progress PM (accepted) PM.2 Project Change Request (if any change to CIs) Plan Execution Report Meeting Minutes Updated Project Repository PM TL WT CUS Project Plan Project Progress PM (accepted) PM.3 Project Report Project Progress Change Request (if TL Assessment and Report any) WT Control Project Plan Acceptance Record PM Deliverables (delivered) PM.4 Project Closure Deliverables (accepted) Project Repository Project Closure Report PM CUS 43 Software Implementation (SI) Profile SI Purpose The purpose of the Software Implementation process is the systematic performance of the analysis, design, construction, integration and tests activities for new or modified software products according to the specifiedrequirements. 44

23 Software implementation requirements As a result of successful implementation of the basic software implementation process: a) Theexecution execution plan andsoftware requirements shall bereviewed and understood by the work team. b) Software requirements shall be defined. c) Software requirements shall be analysed for correctness and testability. d) Software requirements shall be agreed by the Customer or project sponsor. e) Software requirements baseline shall be established and communicated to affected parties. f) Changes to the software requirements shall be evaluated for cost, schedule and technical impact. g) Software architectural and detailed design shall be developed and a baseline shall be established and communicated to affected parties. 45 Software implementation requirements (Cont.) h) Software architectural and detailed design shall have been prepared to describe the software components and their relevant internal and external interfaces. i) Consistency andtraceability between software requirements, software architectural and software detailed design shall be established. j) Software components defined by the detailed design shall be produced. k) Releases of items shall llbe controlled and made available to relevant stakeholders. l) Unit test shall be performed to verify the consistency with software requirements and detailed design. m) Consistency and traceability shall be established between software components and requirements and design. 46

24 Software implementation requirements (Cont.) n) User documentation ti shall hllbe developed. d o) Software shall be produced by integrating software components. p) Software shall be tested and verified, the results shall be recorded and communicated to work team. q) Df Defects identified ifi d in reviews, tests and verifications i shall hllbe corrected. r) Software configuration shall hllbe integrated t and stored din the project repository. A final baseline shall be established and communicated to work team and the customer. s) Product shall be completed and released for use after validation by the customer or project sponsor. 47 SI Activities Input Process Output Related Role(s) Project Plan Project Plan (reviewed and PM SI.1 Software Implementation committed) TL WT Initiation Project Plan (committed) SI.2 Software Requirement Analysis Requirements Specification (validated, baselined) Verification Results Validation Results TL AN WT CUS Project j Plan Software Design Specification TL Requirements AN Specification DES (validated, baselined) SI.3 Software Architectural and Detailed Design (verified, baselined) Test Cases and Test Procedures (verified, baselined) Traceability Matrix Verification Results Project Plan Software Design Specification Traceability Matrix SI.4 Software Construction Software Components (corrected, baselined) Traceability Matrix (updated) TL PR Project Plan Test Cases and Test Procedures Software Components Traceability Matrix SI.5 Software Integration and Tests Software (tested) Test Report Product Operation Guide Software User Documentation Traceability Matrix (updated) TL PR CUS DES AN Project Plan Maintenance Documentation TL Deliverables Verification Results WT SI.6 Product Deliverables (delivered) DES Delivery 48

25 Q&A THANK YOU 49